تاریخ : جمعه 27 مرداد 1391
نویسنده : hamidrezakhouri

تاریخچه ی پیدایش زبان های برنامه نویسی شی گرا

در ابتدای پیدایش علوم کامپیوتر، برنامه‌نویسان کدهایی در سطح ماشین می‌نوشتند. به همین دلیل بیشتر توجه آنان معطوف به مجموعه دستورات ماشین بود. به تدریج زبان‌های سطح بالا ایجاد شد و در نتیجه توجه برنامه‌نویسان بیشتر به اصل مسئله معطوف گردید. اکنون سطح انتزاعی بر روی کامپیوترهای مختلف ایجاد شده است. یعنی برنامه‌ی نوشته شده روی هر ماشین اجرا می‌شود.
در زبان‌های ساخت‌یافته ، برنامه را به تعدادی روال تقسیم می‌نمودند، بدین صورت که هر روال کار خاصی را انجام می‌داد. برنامه‌نویسی شی‌گرایی اجازه می‌دهد تا سیستمی دارای اشیای مرتبط و همکار داشته باشید. کلاس ‌ها این امکان را فراهم می‌کنند که جزییات پیاده‌سازی را پشت واسط برنامه‌نویسی پنهان نمایید. چندشکلی یا چندریختی ، رفتار و واسط مشترکی را برای مفاهیم مشابه نشان می‌دهد. بدین وسیله قادر خواهید بود تا پیمانه‌های خاص و جدیدی را بدون نیاز به دست‌کاری در پیاده‌سازی مفاهیم پایه ایجاد نمایید.

روش‌های برنامه‌نویسی و زبان‌ها در واقع راه ارتباط با ماشین را تعریف می‌کنند. هر روش جدید، شیوه‌های نو را برای تجزیه‌ی مساله ارائه می‌دهد که عبارتند از: کد ماشین، کد مستقل از ماشین، روال‌ها، کلاس‌ها و غیره. هر شیوه‌ی جدید، نگرشی تازه جهت تبدیل نیازهای سیستم به زیرساخت‌های برنامه‌نویسی ارائه می‌دهد. تکامل این نوع شیوه‌های برنامه‌نویسی امکانی را فراهم می‌نماید تا سیستم‌های پیچیده‌تری ایجاد کنید. عکس این مطلب نیز صادق می‌باشد. یعنی سیستم‌های پیچیده می‌توانند پیاده‌سازی شوند.

اکنون، برنامه‌نویسی شی‌گرا به عنوان روش ایجاد پروژه‌های نرم‌افزاری استفاده می‌شود. این شیوه قدرت خود را در مدل‌سازی رفتارهای معمولی نشان داده است. اما این روش به خوبی نمی‌تواند بر روی رفتارهایی که بین چندین پیمانه مشترک وجود دارند، کار کند. برعکس، شیوه‌ی جنبه‌گرا تا حد قابل توجهی این مشکل را برطرف می‌کند.

در سال 1972 پارانز مفهومی به نام جداسازی دغدغه‌ها را مطرح کرده که امروزه جزء مفاهیم اساسی در فرآیند مهندسی نرم‌افزار به شمار می‌آید. این مفهوم به صورت زیر تعریف شده است:
"قابلیت تشخیص، کپسوله‌سازی و کار با دغدغه، هدف و یا مقصود هستند"
دغدغه را می‌توان به عنوان محرکی برای تقسیم نرم‌افزار به بخش‌های قابل مدیریت درنظر گرفت. برای نمونه، یک وظیفه‌مندی خاص نرم افزار و مسائلی که به خواسته‌های غیروظیفه‌مندی مرتبط می‌شوند مانند ثبت وقایع، امنیت و غیره، همگی به عنوان دغدغه هستند، البته با توجه به جداسازی دغدغه‌ها آنها را در قالب واحدهای مستقل کپسوله کرده‌اند.

در سال 1997، مشهورترین رویکرد زبان جنبه‌گرا به نام AspectJ ابتدا توسط گروهی درXerox PARC عمومیت یافت. این گروه روی پروتکل‌ها و ایده‌ی مدل‌سازی دغدغه‌های مشترک کار می‌کردند. در همان حال، گروهی در شرکت IBM برنامه‌نویسی موضوع‌گرا را مطرح کردند. برنامه‌نویسی موضوع‌گرا و عناوین بعدی آن، تحت نام "جداسازی چندبعدی دغدغه‌ها"، به جداسازی و ادغام پیمانه‌های مختلف برنامه‌نویسی بر پایه‌ی دغدغه‌هایی در ابعاد مختلف پرداخته‌اند. [1]

نخستین کار در دانشگاه Twente هلند انجام یافت که در مورد فیلترهای ادغام‌سازی کار می‌کردند. به طوری که در پیاده‌سازی فیلترهایی که رفتار شی را در اجرا پیشرفت می‌دادند دخیل بودند. در دانشگاه Northeastern نیز انتزاعی از ساختار کلاس‌ها انجام گرفت که پشتیبانی بهتری از مفهوم دانش و رفتار عملیاتی ارائه می‌داد. در سال 1997، کریستیانا لوپز از هر دو مقاله استفاده کرد و زبان D-Java را به عنوان اولین مجموعه‌ی رسمی از زبان جنبه‌گرا ارائه نمود.

شیوه‌ی موضوعی اولین روشی بود که مفاهیم جنبه‌گرایی را با زبان مدل‌سازی یکپارچه ادغام کرد. این کار مشترکی از چندین گروه با گروه برنامه‌نویسی موضوع‌گرا است. برنامه‌نویسی موضوع‌گرا به طراحی موضوع‌گرا تبدیل شده و در سال 2001 به Theme/UML تبدیل گردید. تعریف و نمایش دغدغه‌ها برای نخستین بار در مستندات الیسا و گیل مورفی از دانشگاه British Columbia ارائه شد و در سال 2003 به عنوان بخشی از شیوه‌ی موضوعی طراحی جنبه‌گرا به نام Theme/Doc مطرح گردید.

حدود یک دهه‌ی قبل، به دنبال موفقیت درخور توجه ابزار CASE ، چیکوفسکی و کراس مبحث مهندسی معکوس و بازیابی طراحی را مطرح نمودند. تعریفی که آنها از مهندسی معکوس داشتند در زیر ارائه شده است:
"مهندسی معکوس، تحلیل یک سیستم به منظور تشخیص اجزا، ترکیبات فعلی، روابط بینابین آنها، استخراج و تولید تجریدهای موجود در سیستم و داده‌های مربوط به طراحی است." [2]
در دو دهه‌ی قبل، محققان امکاناتی را به منظور کشف، اعمال تغییر، تحلیل، جمع‌بندی، تولید، تجزیه و به تصویر کشیدن محصولات نرم‌افزاری ابداع کردند. این امکانات شامل تهیه‌ی اسناد نرم‌افزاری در شکل‌های گوناگون، نمایش کد میانی، داده و معماری بود. اغلب ابزارهای مهندسی معکوس بر استخراج ساختار درونی سیستم موجود با هدف انتقال آن به ذهن مهندس نرم افزار تمرکز دارد. در هر صورت، این ابزارها راه زیادی در پیش دارند تا به مرحله‌ای برسند که مورد استفاده‌ی روزانه‌ی مهندسان نرم‌افزار قرار گیرند. مطالعه و درک برنامه در صنعت نرم‌افزار به منظور کنترل هزینه و ریسک چرخه‌ی تحولات سیستم‌های نرم‌افزاری از اهمیت بالایی برخوردار می‌باشد.


|
امتیاز مطلب : 12
|
تعداد امتیازدهندگان : 5
|
مجموع امتیاز : 5
موضوعات مرتبط: مقالات عمومی برنامه نویسی , ,
تاریخ : جمعه 27 مرداد 1391
نویسنده : hamidrezakhouri

زبان مدل سازی یكنواخت یا UML چیست ؟

UML شامل تعدادی عنصر گرافیكی است كه از تركیب آنها نمودارهای UML شكل می گیرند . هدف استفاده از نمودارهای مختلف در UML ، ارائه دیدگاه های گوناگون از سیستم است. همانطور كه مهندسین عمران جهت ساختن یك ساختمان پلانهای مختلفی از ساختمان تهیه می كنند ، ما با استفاده از نمودارهای UML نماهای مختلفی از نرم افزار مورد نظر را تهیه می كنیم.
نكته ای كه باید حتما به آن توجه كنید این است كه : مدل UML آنچه كه یك سیستم باید انجام دهد را توضیح می دهد، ولی چیزی درباره نحوه پیاده سازی سیستم نمی گوید.
با توجه به رشد نرم افزارهای پشتیبانی كننده UML امروزه با استفاده از نرم افزارهایی مانند Visio ، Enterprise Architecture و rational rose شما می توانید بعد از كشیدن نمودارهای UML مستقیما نمودارهای خود را به بانك اطلاعاتی و كد تبدیل كنید (البته این نرم افزارها ساختار كد شما را برایتان تولید می كنند!) این نرم افزارها همچنین كد برنامه شما را گرفته و نمودارهای UML برنامه را تولید می كنند. پس از آشنایی با مفاهیم شیء گرایی، در اینجا زبان مدلسازی UML را معرفی کرده و خواهیم دید چگونه این زبان مفاهیم شیء گرایی را پشتیبانی می كند.

مقدمه

زبان مدل سازی یكنواخت ( Unified Modeling Language ) یا UML یك زبان مدلسازی است كه برای تحلیل و طراحی سیستم های شی گرا به كار می‌رود. UML اولین بار توسط شركت Rational ارائه شد و پس از آن از طرف بسیاری از شركت های كامپیوتری و مجامع صنعتی و نرم افزاری دنیا مورد حمایت قرار گرفت؛ به طوریكه تنها پس از یك سال، توسط گروه Object Management Group، به عنوان زبان مدلسازی استاندارد پذیرفته شد. UML توانایی ها و خصوصیات بارز فراوانی دارد كه می‌تواند به طور گسترده‌ای در تولید نرم‌افزار استفاده گردد. در ادامه این مقاله ابتدا به تاریخچة UML و در ادامه به معرفی، ویژگی ها و نمودارهای آن پرداخته می شود.

تاریخچة UML :
دیدگاه شی گرایی (Object Oriented) از اواسط دهه 1970 تا اواخر دهه 1980 در حال مطرح شدن بود. در این دوران تلاش های زیادی برای ایجاد روش های تحلیل و طراحی شی گرا صورت پذیرفت. در نتیجه این تلاش ها بود كه در طول 5 سال یعنی 1989 تا 1994، تعداد متدولوژی های شی گرا از كمتر از 10 متدولوژی به بیش از 50 متدولوژی رسید. تكثر متدولوژی ها و زبانهای شی گرایی و رقابت بین اینها به حدی بود كه این دوران به عنوان "دوران جنگ متدولوژیها" لقب گرفت.

از جمله متدولوژی های پركاربرد آن زمان می توان ازBooch، OOSE، OMT، Fusion، Coad-Yourdan، Shlayer-Mellor و غیره نام برد. فراوانی و اشباع متدولوژیها و روشهای شی گرایی و نیز نبودن یك زبان مدلسازی استاندارد، باعث مشكلات فراوانی شده بود. از یك طرف كاربران از متدولوژیهای موجود خسته شده بودند، زیرا مجبور بودند از میان روشهای مختلف شبیه به هم كه تفاوت كمی در قدرت و قابلیت داشتند یكی را انتخاب كنند. بسیاری از این روشها، مفاهیم مشترك شی گرایی را در قالب های مختلف بیان می کردند كه این واگرایی و نبودن توافق میان این زبانها، كاربران تازه كار را از دنیای شی گرایی زده می‌ کرد و آنها را از این حیطه دور می‌ساخت. عدم وجود یك زبان استاندارد، برای فروشندگان محصولات نرم افزاری نیز مشكلات زیادی ایجاد كرده بود.

اولین تلاشهای استانداردسازی از اكتبر 1994 آغاز شد، زمانی كه آقای Rumbaurgh صاحب متدولوژی OMT به آقای Booch در شركت Rational پیوست و این دو با تركیب متدولوژیهای خود، اولین محصول تركیبی خود به نام "روش یكنواخت" را ارائه دادند. در سال 1995 بود كه با اضافه شدن آقای Jacobson به این دو، روش یكنواخت ارائه شده با روش OOSE نیز تركیب شد و این خود سبب ارائه UML نسخة 0.9 در سال 1996 گردید. سپس این محصول به شركتهای مختلفی در سراسر جهان به صورت رایگان ارائه شد و استقبال شدید شركت ها از این محصول و تبلیغات گسترده شركت Rational، سبب آن شد كه گروه OMG، نسخة 1.0 UML را به عنوان زبان مدلسازی استاندارد خود بپذیرد. تلاشهای تكمیلی UML استاندارد ادامه پیدا كرد و نسخة 1.1 آن در سال 1997 و نسخه 1.3 آن در سال 1999 ارائه گردید.

UML یا زبان مدلسازی یكنواخت، زبانی است برای مشخص كردن (Specify)، مصورسازی (Visualize)، ساخت (Construction) و مستندسازی (Documenting) سیستمهای نرم افزاری و غیر نرم افزاری و نیز برای مدلسازی سیستمهای تجاری.

اما چرا مدل و مدلسازی ؟

ایجاد یك مدل برای سیستمهای نرم افزاری قبل از ساخت یا بازساخت آن، به اندازه داشتن نقشه برای ساختن یك ساختمان ضروری و حیاتی است. بسیاری از شاخه های مهندسی، توصیف چگونگی محصولاتی كه باید ساخته شوند را ترسیم می كنند و همچنین دقت زیادی می كنند كه محصولاتشان طبق این مدلها و توصیفها ساخته شوند. مدلهای خوب و دقیق در برقراری یك ارتباط كامل بین افراد پروژه، نقش زیادی می توانند داشته باشند. شاید علت مدل كردن سیستمهای پیچیده این باشد كه تمامی آن را نمی توان یك باره مجسم كرد، بنابراین برای فهم كامل سیستم و یافتن و نمایش ارتباط بین قسمتهای مختلف آن، به مدلسازی می‌پردازیم. UML زبانی است برای مدلسازی یا ایجاد نقشه تولید نرم افزار.

به عبارت دیگر، یك زبان، با ارائه یك فرهنگ لغات و یك مجموعه قواعد، امكان می دهد كه با تركیب كلمات این فرهنگ لغات و ساختن جملات، با یكدیگر ارتباط برقرار كنیم. یك زبان مدلسازی، زبانی است كه فرهنگ لغات و قواعد آن بر نمایش فیزیكی و مفهومی آن سیستم متمركزند. برای سیستمهای نرم افزاری نیاز به یك زبان مدلسازی داریم كه بتواند دیدهای مختلف معماری سیستم را در طول چرخه تولید آن، مدل كند.

فرهنگ واژگان و قواعد زبانی مثل UML به شما می گویند كه چگونه یك مدل را بسازید و یا چگونه یك مدل را بخوانید. اما به شما نمی گویند كه در چه زمانی، چه مدلی را ایجاد كنید. یعنی UML فقط یك زبان نمادگذاری (Notation) است نه یك متدولوژی. (توضیحات بیشتر در سایر مقالات سایت میکرو رایانه) یك زبان نمادگذاری شامل نحوه ایجاد و نحوه خواندن یك مدل می باشد، اما یك متدولوژی بیان می كند كه چه محصولاتی باید در چه زمانی تولید شوند و چه كارهایی با چه ترتیبی توسط چه كسانی، با چه هزینه‌ای، در چه مدتی و با چه ریسكی انجام شوند.


UML دارای ویژگیهای بارز فراوانی است كه در این قسمت به آنها می پردازیم. UML یك زبان مدلسازی است اما چیزی فراتر از چند نماد گرافیكی است. به طوریكه در ورای این نمادها، یك سمانتیك (معناشناسی) قوی وجود دارد، به طوریكه یك تولیدكننده می‌تواند مدلهایی تولید كند كه تولید‌كننده های دیگر و یا حتی یك ماشین آن را بخواند و بفهمد. بنابراین یكی دیگر از نقش های مهم UML "تسهیل ارتباط" بین اعضای پروژه و یا بین تولیدكنندگان مختلف می باشد. این ارتباط بسیار مهم است. شاید دلیل اصلی اینكه تولید نرم افزار به صورت فریبنده ای دشوار است، همین عدم ارتباط مناسب بین اعضای پروژه باشد و اگر در تولید نرم افزار، بین اعضای پروژه گزارشهای هفتگی و مداوم وجود داشته باشد، بسیاری از این دشواریها برطرف خواهد شد.

البته این را هم باید در نظر گرفت كه UML كمی پیچیده است و این به خاطر آن است كه سعی شده است نمودارهایی فراهم شود كه در هر موقعیتی و با هر ترتیبی قابل استفاده باشند. دلیل دیگر پیچیدگی از آنجا ناشی می شود كه UML تركیبی است از زبانهای مختلف، كه برای حفظ سازگاری و جمع كردن خصوصیات مثبت آنها، ناگزیر از پذیرش این پیچیدگی می باشد.

UML موفقیت طرح را تضمین نمی كند، اما در عین حال خیلی چیزها را بهبود می‌بخشد. به عنوان مثال استفاده از UML، تا حد زیادی، هزینه های ثابتی نظیر آموزش و استفاده مجدد از ابزارها را در هنگام ایجاد تغییر در سازمان و طرحها كاهش می دهد.

مساله دیگر اینكه، UML یك زبان برنامه نویسی بصری (visual) نیست، اما مدلهای آن را می‌توان مستقیماً به انواع زبانهای مختلف ارتباط داد. یعنی امكان نگاشت از مدلهای UML به كد زبانهای برنامه نویسی مثل Java و ++C وجود دارد كه به این عمل "مهندسی رو به جلو" می گویند.

عكس این عمل نیز ممكن است؛ یعنی این امكان وجود دارد كه شما بتوانید از كد یك برنامه زبانی شی گرا، مدلهای UML معادل آن را به دست آورید. به این عمل "مهندسی معكوس" می گویند. مهندسی رو به جلو و معكوس از مهمترین قابلیت های UML به شمار می روند، البته نیاز به ابزار Case مناسبی دارید كه از این مفاهیم پشتیبانی كنند.

اگر با زبانهای مدلسازی دیگر كار كرده باشید، برای كار با UML مشكل چندانی نخواهید داشت. اما برای شروع كار با UML به عنوان اولین زبان مدلسازی، بهتر است فقط با نمودارهای خاصی كار كنید. برای این كار بهتر است ابتدا با نمودارهای مورد كاربرد و تعامل كار كنید و پس از مدتی كار و آشنا شدن با ویژگیهای اولیه آن، به یادگیری و استفاده از نمودارها و اجزای دیگر بپردازید. در مقایسه با زبانهای مدلسازی دیگر مثل ER و زبان فلوچارتی DR، زبان UML نمودارهای قوی تر و قابل فهم تری را ارائه می دهد كه شامل تمامی مراحل چرخه حیات تولید نرم افزار (تحلیل، طراحی، پیاده سازی و تست) می‌شود.

یكی دیگر از ویژگی های مهم UML این است كه مستقل از متدولوژی یا فرایند تولید نرم افزار می باشد و این بدان معنی است كه شما برای استفاده از UML، نیاز به استفاده از یك متدولوژی خاص ندارید و می توانید طبق متدولوژی های قبلی خود عمل كنید با این تفاوت كه مدلهایتان را با UML نمایش می دهید. البته مستقل بودن از متدولوژی و فرایند تولید، یك مزیت برای UML می‌باشد؛ زیرا بسیاری از انواع پروژه ها و سیستمها نیاز به متدولوژی خاص خود دارند. اگر UML در پی پیاده كردن همه اینها بر می آمد، یا بسیار پیچیده می شد و یا استفاده خود را محدود می كرد. البته متدولوژیهایی براساس UML در حال شكل گیری می باشند.

از دیگر ویژگیهای UML می توان به پشتیبانی از مفاهیم سطح بالای شی گرایی مثل Collaboration، Framework، Pattern و Component اشاره كرد. همچنین UML با استفاده از یك سری مكانیزم های گسترش پذیر امكان می دهد كه بتوان زبانهای مدلسازی جدیدتری (با گسترش مفاهیم پایه ای موجود) ایجاد كرد.

روند حركت به سمت UML در جهان:
قبل از ارائه UML، زبان مدلسازی استانداردی وجود نداشت و استفاده كنندگان مجبور بودند از میان زبانهای مختلف موجود ‌كه تقریباً هیچ کدام كامل نبودند و تفاوتهایی با هم داشتند، یكی را انتخاب كنند. تفاوتهای زبانهای مدلسازی، چندان قدرت مدلسازی را افزایش نداده بود، اما در عوض باعث افول صنعت شی گرایی و سردرگمی كاربران شده بود. در چنین شرایطی طبیعی بود كه استقبال زیادی از چنین زبان مدلسازی استانداردی بشود كه ویژگیهای بارز زیادی داشت. بسیاری از شركتها در همان اوایل كار به UML روی آوردند و تعداد دیگری نیز پس از تثبیت UML، آن را به عنوان استراتژی تولید و مستندسازی خود پذیرفتند.

OMG كه كنسرسیومی است متشكل از 700 شركت معتبر آمریكا، از UML حمایت كرد و آن را به عنوان زبان مدلسازی استاندارد خود اعلام كرد. البته علاوه بر استاندارد شدن، حمایت جداگانه شركت های بزرگ دنیا مثل Hewlett-Packard، I-Logix، Microsoft، IBM، Oracle و بسیاری دیگر، خود سبب افزایش كاربرد آن در محافل صنعتی و نرم افزاری دنیا گردید.


|
امتیاز مطلب : 8
|
تعداد امتیازدهندگان : 4
|
مجموع امتیاز : 4
موضوعات مرتبط: مقالات عمومی برنامه نویسی , ,

صفحه قبل 1 صفحه بعد

آخرین مطالب

/
از این که به وبلاگ من سر زدید خیلی خیلی ممنونم باتشکر حمیدرضاخوری